Recently, the evolution of embedded systems has shown a strong trend towards application-specific, single-chip solutions. As a result, application-specific instruction set processors (ASIP) are more and more replacing off-the-shelf processors in such systems-on-chip (SoC). One of the key factors for a successful design of application-specific instruction set processors (ASIP) is an efficient architecture exploration phase. The objective of the architecture exploration is to reduce the huge design space in order to find the best-suited architecture for a given application under a number of constraints, such as performance, power consumption, chip size, and flexibility. Although there are a number of analytical approaches, large parts of the design space exploration still have to be carried out by simulating alternative architecture implementations. Therefore, design methodology and simulation performance have a significant impact on the efficiency of the exploration process, and hence, on the quality of the architecture implementation and the design time.
FIG. 1 depicts a conventional simulation environment in which a separate debugger is required to observe and control each simulation. The environment is used to simulate an architecture (or platform) that in this case includes multiple processor cores and hardware, such that the platform may be debugged. The hardware debugger 150 and each processor core debugger (e.g., CPU1 and CPU2 debuggers 170) are separate operating system processes. The hardware debugger 150 executes a simulation kernel 160 comprising a hardware simulation 180 and two processor core simulations (CPU1 and CPU2 simulations 175). The hardware debugger 150 has an application program interface (API) to communicate with the hardware simulation 180. However, in order for the hardware debugger 150 to communicate with the processor core simulations 175, which is needed to perform the overall simulation, the processor core simulations 175 each have a software wrapper 185. However, the software wrapper 185 does not allow the processor core simulations 175 to be debugged via the hardware debugger 150. That is, the software wrappers do not allow control and observation of the actual simulation. Rather, separate processor core debuggers 170 are required to control and observe the processor core simulations 175, such that the processor cores may be debugged. Thus, a separate debugger is required to control and observe each simulation in order to debug the platform.
One implication of this conventional environment is that the various debuggers are not synchronized. For example, if the hardware simulation is halted (e.g., hits a watchpoint) the two processor core simulations are unaware of this event, and are thus not synchronized with the hardware simulation. Furthermore, the lack of synchronization prevents rewinding the simulations together to view a previous (synchronized) state of the simulations. Another drawback of the conventional environment is that because a debugger can only set a breakpoint or watchpoint for an event in a simulation that it controls, breakpoints/watchpoints involving multiple simulations are not possible.